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(3) Status of Claims 

This application was filed with claims 1 through 1 1 all of which were cancelled 
and replaced by new claims 12 to 99. Of the new claims, claims 35, 67, 82 & 95 have 
been amended once to attend to a 35 U.S.C. §112 indefiniteness rejection. Otherwise, 
claims 12 to 99 are pending as previously presented. Consequently, it is the rejection of 
claims 12 to 99 that is being appealed. The claims as currently pending are set forth in 
the Appendix. 

(4) Status of Amendments 

A paper entitled "Response to Office Action Mailed March 31 , 2004" was filed 
June 1, 2004. The amendment of this response was to claims 35, 67, 82 & 96 in 
response to a 35 U.S.C. §112 indefiniteness rejection. 

By an Advisory Action mailed June 23, 2004, the Examiner entered the 
Response and has maintained his rejection of claims 12 to 16, 20 to 37, 39 to 48, 52 to 
69, 71 to 75, 78 to 82, 84 to 88, 91 to 95 & 97 to 99. It is the continued rejection of these 
claims that is being appealed. 

(5) Summary of the Invention 

The present invention is directed to a method and apparatus for transporting 
multi-protocol datagrams over a point to poin t protocol (PPP) link in an asynchronous 
transport network by encapsulating the datagrams into asynchronous transport network 
mini-cells. In the method of the invention, a channel iden tifier fCID) field in a header of a 
mini-cell is utilized to identify, through association with a re spective PPP identifier (PIP), 
the multi-protocol datagram that is encapsulated in th e mini-cell. 

Consequently, the present invention enables PPP datagrams to be encapsulated 
in AAL2 mini-cells rather than PPP's native High Level Data Link Control (HDLC) 
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protocol for modem transport, so that PPP can be transported over ATM and, in 
particular, AAL2 access links. 

(6) Issues 

The following issues are presented: 

1. The rejection of claims 12 to 16, 20 to 37, 39 f 41 to 48, 52 to 69, 71 to 75, 
78 to 82, 84, 86 to 88, 91 to 95, 97 & 99 under 35 U.S.C. §103(a) as being un-patentable 
over Lyons et al (US 6075798) in view of Nagami et al (US 5,822,319); and 

2. The rejection of claims 40, 85, & 98 under 35 U.S.C. §1 03(a) as being un- 
patentable over Lyons et al (US 6,075,798) in view of Nagami et al (US 5,822,319) and 
further in view of Lin et al (US 5742599). 

(7) Grouping of Claims 

Claims 12 to 99 can be considered as a group. 

(8) Argument 

Referring to issue 1, the Examiner has accepted that Lyons does not teach the 
system of the invention of encapsulating multi-protocol datagrams in mini-cells and 
associating Point to Point Protocol identifiers (PIDs) of the datagrams within the CID 
fields of the mini-cells. In fact, although not expressly stated in Lyons, it is implicit 
therefrom that the CID field of the mini-cells' headers is used entirely for its properly 
defined function of identifying AAL channels for mini-cell transport in ATM packets 
across an ATM network. Consequently, there is no motivation for a skilled person to 
contemplate modifying the system taught by Lyons by using the CID field in the manner 
of the first embodiment proposed by the present invention. It should also be noted that 
Lyons does not teach the feature of the invention of transporting asynchronous transport 
packets into which the mini-cells encapsulating multi-protocol datagrams as aforesaid 
have been assembled over a Point to Point Protocol link through the asynchronous 
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transport network. Lyons is entirely silent as to its use with the PPP. This will be 
discussed more fully below. 

Nagami also does not teach the feature of transporting asynchronous transport 
packets into which the mini-cells encapsulating multi-protocol datagrams in accordance 
with the invention have been assembled over a Point to Point Protocol link through the 
asynchronous transport network. Nor does Nagami teach the system of further 
embodiments of the invention of encapsulating multi-protocol datagrams within mini-cells 
and associating Point to Point Protocol identifiers (PIDs) of the datagrams with the CID 
fields of the mini-cells. In fact, Nagami comprises a router cut-through technique 
wherein, once datagram classification has been done once, the result can be stored 
against short-form information such as connection identifiers in routers without further 
recourse to examining the content of the datagrams. As such, the whole thrust of 
Nagami is to avoid referring to the content of a datagram including header information 
during datagram transport (cf column 1 1 lines 57 to 67 and column 2, lines 37 to 40)). 
Instead, Nagami proposes using a table stored in a router which registers a 
correspondence between a virtual connection identifier and protocol type information as 
a means of identifying a transfer target network interface for a datagram without needing 
to access the content of the datagram. Consequently, in Nagami, the virtual connection 
identifier and protocol type information stored in the router table comprises knowledge 
local to the router in contrast with the present invention in which the connections are 
established end to end a priori by the ANP(Q2630.1) signalling protocol. Thus, Nagami 
makes no reference to associating a PPP identifier (PID) with the CID field of a mini-cell 
in an asynchronous transport network and is silent as to its use with the PPP. 

In view of the above, it is impossible to see how it can be concluded that the 
combined teachings of Lyons and Nagami teach or suggest aH of the claims limitations 
of the independent claims currently pending in the present application notwithstanding 
the lack of any motivation to do so nor the fact that to use the CID field in Lyons in the 
manner proposed by the present invention cannot possibly succeed and so offers no 
reasonable expectation of success. The motivation suggested at the bottom of page 3 
of the office action mailed March 31, 2004 is so broad as to be meaningless in the 
context of a rejection under 35 U.S.C. §1 03(a). It is always desirable to improve 
technology for economic reasons but that is not sufficiently succinct as to motivate one 
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skilled in that art to specifically consider modifying Lyons or combining the teachings of 
Lyons and Nagami. In any event, as already discussed, such a combination fails to 
teach all of the claim limitations and would not in any event provide a workable system. 

In the Advisory Action mailed June 23, 2004, the Examiner has justified his 
continued rejection of claims 12 to 16, 20 to 37, 39, 41 to 48, 52 to 69, 71 to 75, 78 to 
82, 84, 86 to 88, 91 to 95, 97 & 99 on the premise that Lyons, although not explicitly 
using the statement (term) "point-to-point" is, however, based on the structure and 
operation of the reference (point-to-point) system such that one of ordinary skill in the art 
would conclude that the system is a kind system that applies the Point-to-Point Protocol. 
This premise is incorrect for a number of reasons as will now be explained. 

First and foremost the Examiner must acknowledge the fact that the Point to 
Point Protocol (PPP) is specifically the "Point to Point Protocol" (RFC1661 defined by 
the IETF) and has specific syntax and semantics. It is not a common or garden point-to- 
point link as implied by the Examiner's grounds for rejecting the above identified claims. 
To quote from that RFC: 

"The Point-to-Point Protocol (PPP) provides a standard method for transporting multi- 
protocol datagrams over point-to-point links. PPP is comprised of three main 
components: 

1. A method for encapsulating multi-protocol datagrams. 

2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link 
connections. 

3. A family of Network Control Protocols (NCPs) for establishing and configuring 
different network-layer protocols. " 

PPP also has a particular frame structure which is based on HDLC (ISO 3309- 
1979), as modified by ISO 3309:1984/PDAD1 "Addendum 1: Start/Stop Transmission.) 
The Link Control Protocol is responsible for the establishment, user authentication, link 
configuration and IP address allocation. It may also optionally test the link quality. The 
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Network Control Protocol, which may be opened and closed at any time, is used to 
determine whether to use TCP/IP, Appletalk, IPX or any other network protocol. There 
can be more than one network protocol running simultaneously across the link 
configured by the LCP. 

To better understand why the Examiner's understanding of what Lyons 
contributes to the art is incorrect, first consider what Lyons does not disclose and then 
consider what Lyons does, in fact, disclose. 

What Lyons "does not disclose" is how to map the Point-to-Point Protocol 
(PPP) RFC1661 to AAL-2. Lyons does not state how HDLC is terminated (and not even 
merely encapsulated), which fields of the PPP formatted HDLC frame are significant, 
how those fields should map into fields of the AAL-2 connection, the relationship of LCP 
to the AAL2 Negotiation Procedures Q2630.1, how AAL-2 CIDs should be mapped to 
the LCP, how AAL-2 CIDs should be mapped to the NCP, how the 2 octet protocol field 
of PPP could be carried in AAL-2, how a compressed PPP protocol field could be carried 
in the CID field, how an uncompressed PPP protocol field could be mapped across the 
AAL-2 CID and PDU, how the length field of AAL-2 should be encoded to carry a PPP 
frame, how segmentation and reassembly should and could work, how similar network 
protocols could all be mapped to one AAL-2 CID even where they may be from more 
than one PPP LCP session. 

Lyons' focus is voice communications, and in particular the dynamic change of 
voice compression coding during a single call on a given AAL-2 CID. It is not at all 
obvious given Lyons' repeated statements regarding voice applications that data 
communications are envisaged by his method. It is also not obvious how Lyons 
teachings could be extended or reused to convey PPP in any way. The only "novel" 
aspect in Lyons is the use of an extension header, but the format and purpose are only 
related to voice communication. The association of this extension header to UUI (RES) 
codepoints does not include codepoints used for data communication, and the explicit 
statement regarding the later-determined data codepoints in Lyons' figure 8 is: "reserved 
for future use". Therefore no use or intimation of use is stated absolutely, and the use of 
that extension header for a data application with all its voice controls is neither obvious 
nor likely to be worthwhile. Significantly, the present invention does not use an 
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extension header, and more pointedly the present invention does not use a priori 
defined, table-driven interpretation of UUI in conjunction with the first bit of the first octet 
of the payload of an AAL-2 minichannel. 

In the present invention, the UUI field is used in its standard way (and not in 
Lyons* way) to signify the start, middle or end of a long and fragmented packet, and 
carries no further meaning or assistance to interpreting and processing PPP. 

What Lyons does disclose is the use of the UUI field change of codepoint to 
signify the ephemeral use of a one octet extension to the header. That extension header 
is broken down into a single bit to signify, in conjunction with the particular UUI 
codepoint (fig 8), the voice compression coding change, the continuation of the 
sequence numbering (not explained but part of the UUI codepoints 0-15 in the AAL2 
standard) and error detection means. It is not fully explained but a transition from any 
codepoint 0-15 to one of 16-19 for a short period (timed or acknowledge receipt) means 
that the payload of the minicell carries the extra octet of the extension header. It is also 
not fully explained but after receipt of the extension header, the codepoint must revert to 
the proper codepoint 0-15 that would be seamlessly the next in sequence (including the 
ones which carried any one of the codepoints 16-19), before any further change can be 
made. The change in voice codec remains until call termination or further transition 
between the two sets of codepoints. 

This is not how the AAL-2 standard works in signifying changes within profiles, 
nor how sequence numbering works. Lyons proposal suffers several disadvantages 
over the standardized method, which means that the disclosure would not be referred to 
and is unlikely to be employed by a skilled addressee for any application because of 
incompatibility. 

Lyons discloses already known use of the AAL-2 CID to signify the Logical Link 
Connection (LLC) ID for a given user, but no further significance is attached to this or its 
use outside of voice communications. Lyons discloses already known end-to-end 
negotiation to assign a CID, but again no further significance is attached to this except to 
establish or terminate an end-to-end user voice call. 
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Applicant therefore fails to see how Lyons could inspire any further application 
than the AAL-2 standard could inspire in its own right, especially given all the latter's 
further advantages. Applicant also fails to see how it would have been obvious that in 
their contemporaneous form, either of Lyons or Nagami could incorporate PPP without 
significant skill and inventiveness being applied to ensure proper and worthwhile 



In view of the foregoing, the rejection of claims 12 to 16, 20 to 37, 39, 41 to 48, 
52 to 69, 71 to 75, 78 to 82, 84, 86 to 88, 91 to 95, 97 & 99 under 35 U.S.C. §1 03(a) as 
being un-patentable over Lyons in view of Nagami cannot be sustained. 

Referring to issue 2, the rejection of claims 40, 85, & 98 under 35 U.S.C. §1 03(a) 
as being un-patentable over Lyons in view of Nagami and further in view of Lin is moot. 



The Examiner has been demonstrated to be in error in rejecting the claims, and reversal 
is therefore urged. 



operation. 



Conclusion 



Respectfully submitted, 



Date: August 23, 2004 




Barnes & Thornburg LLP 
PO Box 2786 



Chicago IL 60690-2786 
(312) 357-1313 Telephone 
(312) 759-5646 Facsimile 
(312)214-4811 Direct 
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APPENDIX 



1.-11. (cancelled) 

12. A method of transporting multi-protocol datagrams over a point to point 
protocol (PPP) link through an asynchronous transport network, comprising the 
steps of: 

encapsulating multi-protocol datagrams into payloads of asynchronous 
transport network mini-cells, each mini-cell having a header in addition to a 
payload, the header including a channel identifier (CID) field; 

for each mini-cell, associating a PPP identifier of the datagram being 
encapsulated therein with the CID field of the mini-cell; 

assembling said mini-cells into transport packets; and 

transporting said packets over said point to point link through the 
asynchronous transport network. 

13. A method as claimed in claim 12, wherein said PPP identifier identifies a 
PPP session. 

14. A method as claimed in claim 12, wherein said PPP identifier identifies at 
least one PPP protocol within a PPP session. 

15. A method as claimed in claim 12, wherein the PPP identifier identifies at 
least one session within a protocol of a PPP session. 

16. A method as claimed in claim 12, wherein the step of associating a PPP 
identifier with the CID field of a mini-cell comprises inserting a PPP identifier into 
the CID field of the mini-cell. 

17. A method as claimed in claim 16, wherein the PPP identifier of a multi- 
protocol datagram comprises two octets, a most significant octet and a least 
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significant octet, and the method includes the step of inserting only the least 
significant octet of the PPP identifier into the CID field of a mini-cell. 

18. A method as claimed in claim 17, wherein it includes the step of inserting 
the most significant octet of the PPP identifier in a first byte of the mini-cell 
payload adjacent the header and to indicating the presence of said most 
significant octet in said first byte of the mini-cell payload by making a value of a 
least significant bit (LSB) of the least significant octet to be "1". 

19. A method as claimed in claim 18, wherein a LSB of the most significant 
octet of the PPP identifier is utilised as a bit parity check for error detection. 

20. A method as claimed in claim 12, wherein the step of associating a PPP 
identifier with the CID field of a mini-cell comprises assigning a pre-allocated 
PPP identifier number to a respective mini-cell CID value and inserting the CID 
value into the CID field of the mini-cell. 

21. A method as claimed in claim 20, wherein the step of assigning a pre- 
allocated PPP identifier number to a CID value and inserting said CID value into 
the CID field of a mini-cell includes obtaining the CID value corresponding to a 
pre-allocated PPP identifier number from a pre-configured table containing a list 
of pre-allocated PPP identifiers numbers and corresponding CID values. 

22. A method as claimed in claim 20, wherein the step of assigning a pre- 
allocated PPP identifier number to a CID value and inserting said CID value in 
the CID field of a mini-cell comprises assigning said pre-allocated PPP identifier 
number to said CID value on set-up of a PPP link, said assignment being carried 
out by a management function. 
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23. A method as claimed in claim 12, wherein the asynchronous transport 
network is an asynchronous transport mode (ATM) network and the mini-cells 
are ATM adaptation layer 2 (AAL2) mini-cells. 

24. A method as claimed in claim 23, wherein it includes the step of mapping 
a PPP session to a single AAL2 channel. 

25. A method as claimed in claim 23, wherein it includes the step of mapping 
at least one protocol of a PPP session to an AAL2 channel. 

26. A method as claimed in claim 23, wherein it includes the step of mapping 
at least one session of a specified PPP protocol to an AAL2 channel. 

27. A method as claimed in claim 23, wherein it includes the step of mapping 
several PPP sessions to a same AAL2 channel. 

28. A method as claimed in claim 23, wherein it includes the step of mapping 
several protocols from different PPP sessions to a same AAL2 channel. 

29. A method as claimed in claim 28, wherein the several protocols from 
different PPP sessions comprise the same protocol from each of the different 
PPP sessions. 

30. A method as claimed in claim 23, wherein it includes the step of mapping 
at least one session of a specified PPP protocol of several PPP sessions to a 
same AAL2 channel. 

31. A method as claimed in claim 23 wherein it includes a mapping step, said 
mapping step comprising a combination of any of: 

mapping a PPP session to a single AAL2 channel; 

mapping at least one protocol of a PPP session to an AAL2 channel; 
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mapping at least one session of a specified PPP protocol to an AAL2 
channel; 

mapping several PPP sessions to a same AAL2 channel; 
mapping several protocols from different PPP sessions to a same AAL2 
channel; and 

mapping at least one session of a specified PPP protocol of several PPP 
sessions to a same AAL2 channel; 

wherein said AAL2 channels comprise an ATM virtual circuit connection 

(VCC). 

32. A method as claimed in any one of claims 23 to 31 , wherein it includes the 
step of scheduling transport of ATM mini-cells of said AAL2 channels according 
to the type of PPP datagrams encapsulated in the mini-cells being transported in 
respective AAL2 channels. 

33. A method as claimed in claim 23 wherein it includes a mapping step, said 
mapping step comprising one of: 

mapping a PPP session to a single ATM virtual channel connection 

(VCC); 

mapping at least one protocol of a PPP session to an ATM VCC; 
mapping at least one session of a specified PPP protocol to an ATM VCC 
mapping several PPP sessions to a same ATM VCC; 
mapping several protocols from different PPP sessions to a same ATM 
VCC; and 

mapping at least one session of a specified PPP protocol of several PPP 
sessions to a same ATM VCC. 

34. A method as claimed 23, wherein it includes the step of multiplexing mini- 
cells into an ATM virtual channel connection (VCC). 
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35. A method as claimed in claim 34, wherein said step of multiplexing mini- 
cells into an ATM virtual channel connection (VCC) includes multiplexing mini- 
cells encapsulating PPP datagrams and mini-cells encapsulating non-PPP 
datagrams into the ATM VCC. 

36. A method as claimed in claim 35, wherein said PPP traffic data comprises 
voice traffic data. 

37. A method as claimed in claim 23, wherein the multi-protocol datagrams 
are encapsulated into mini-cells of variable lengths. 

38. A method as claimed in claim 23, wherein multi-protocol datagrams 
comprising delay sensitive traffic are encapsulated into mini-cells comprising a 
first channel of an ATM virtual circuit (VC) and datagrams comprising delay 
insensitive traffic are encapsulated into mini-cells comprising a second channel 
of said ATM VC. 

39. A method as claimed in claim 23, wherein said step of assembling mini- 
cells into transport packets comprises assembling mini-cells into ATM packets. 

40. A method as claimed in claim 23, wherein said step of assembling mini- 
cells into transport packets comprises assembling mini-cells directly into MPEG- 
TS frames. 

41. A method as claimed in claim 23, wherein said step of assembling mini- 
cells into transport packets comprises assembling mini-cells directly into TDMA 
time slots. 

42. A method as claimed in claim 12, wherein it includes the step of encoding 
a flag in a user to user information (UUI) field of a mini-cell to indicate whether an 
encapsulated datagram extends into a payload of a next mini-cell. 
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43. A method as claimed in claim 12, wherein the step of encapsulating a 
datagram in a mini-cell includes inserting the PPP identifier, a payload of the 
datagram and an optional trailer into the payload of the mini-cell. 

44. A method of encapsulating point to point protocol (PPP) datagrams into 
payloads of asynchronous transport network mini-cells, each mini-cell having a 
header in addition to a payload, the header including a channel identifier (CID) 
field, the method comprising the steps of: 

encapsulating the PPP datagrams into the payloads of the asynchronous 
transport network mini-cells; 

for each mini-cell, associating a PPP identifier of the datagram being 
encapsulated therein with the CID field of the mini-cell; and 

assembling said mini-cells into transport packets. 

45. A method as claimed in claim 44, wherein said PPP identifier identifies a 
PPP session. 

46. A method as claimed in claim 44, wherein said PPP identifier identifies at 
least one PPP protocol within a PPP session. 

47. A method as claimed in claim 44, wherein the PPP identifier identifies at 
least one session within a protocol of a PPP session. 

48. A method as claimed in claim 44, wherein the step of associating a PPP 
identifier with the CID field of a mini-cell comprises inserting a PPP identifier into 
the CID field of the mini-cell. 

49. A method as claimed in claim 48, wherein the PPP identifier of a multi- 
protocol datagram comprises two octets, a most significant octet and a least 
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significant octet, and the method includes the step of inserting only the least 
significant octet of the PPP identifier into the CID field of a mini-cell. 

50. A method as claimed in claim 49, wherein it includes the step of inserting 
the most significant octet of the PPP identifier in a first byte of the mini-cell 
payload adjacent the header and to indicating the presence of said most 
significant octet in said first byte of the mini-cell payload by making a value of a 
least significant bit (LSB) of the least significant octet to be "1". 

51. A method as claimed in claim 50, wherein a LSB of the most significant 
octet of the PPP identifier is utilised as a bit parity check for error detection. 

52. A method as claimed in claim 44, wherein the step of associating a PPP 
identifier with the CID field of a mini-cell comprises assigning a pre-allocated 
PPP identifier number to a respective mini-cell CID value and inserting the CID 
value into the CID field of the mini-cell. 

53. A method as claimed in claim 52, wherein the step of assigning a pre- 
allocated PPP identifier number to a CID value and inserting said CID value into 
the CID field of a mini-cell includes obtaining the CID value corresponding to a 
pre-allocated PPP identifier number from a pre-configured table containing a list 
of pre-allocated PPP identifiers numbers and corresponding CID values. 

54. A method as claimed in claim 52, wherein the step of assigning a pre- 
allocated PPP identifier number to a CID value and inserting said CID value in 
the CID field of a mini-cell comprises assigning said pre-allocated PPP identifier 
number to said CID value on set-up of a PPP link, said assignment being carried 9 
out by a management function. 
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55. A method as claimed in claim 44, wherein the asynchronous transport 
network is an asynchronous transport mode (ATM) network and the mini-cells 
are ATM adaptation layer 2 (AAL2) mini-cells. 

56. A method as claimed in claim 55, wherein it includes the step of mapping 
a PPP session to a single AAL2 channel. 

57. A method as claimed in claim 55, wherein it includes the step of mapping 
at least one protocol of a PPP session to an AAL2 channel. 

58. A method as claimed in claim 55, wherein it includes the step of mapping 
at least one session of a specified PPP protocol to an AAL2 channel. 

59. A method as claimed in claim 55, wherein it includes the step of mapping 
several PPP sessions to a same AAL2 channel. 

60. A method as claimed in claim 55, wherein it includes the step of mapping 
several protocols from different PPP sessions to a same AAL2 channel. 

61. A method as claimed in claim 60, wherein the several protocols from 
different PPP sessions comprise the same protocol from each of the different 
PPP sessions. 

62. A method as claimed in claim 55, wherein it includes the step of mapping 
at least one session of a specified PPP protocol of several PPP sessions to a 
same AAL2 channel. 

63. A method as claimed in claim 55 wherein it includes a mapping step, said 
mapping step comprising a combination of any of: 

mapping a PPP session to a single AAL2 channel; 

mapping at least one protocol of a PPP session to an AAL2 channel; 
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mapping at least one session of a specified PPP protocol to an AAL2 
channel; 

mapping several PPP sessions to a same AAL2 channel; 
mapping several protocols from different PPP sessions to a same AAL2 
channel; and 

mapping at least one session of a specified PPP protocol of several PPP 
sessions to a same AAL2 channel; 

wherein said AAL2 channels comprise an ATM virtual circuit connection 

(VCC). 

64. A method as claimed in any one of claims 55 to 63, wherein it includes the 
step of scheduling transport of ATM mini-cells of said AAL2 channels according 
to the type of PPP datagrams encapsulated in the mini-cells being transported in 
respective AAL2 channels. 

65. A method as claimed in claim 55 wherein it includes a mapping step, said 
mapping step comprising one of: 

mapping a PPP session to a single ATM virtual channel connection 

(VCC); 

mapping at least one protocol of a PPP session to an ATM VCC; 
mapping at least one session of a specified PPP protocol to an ATM VCC 
mapping several PPP sessions to a same ATM VCC; 
mapping several protocols from different PPP sessions to a same ATM 
VCC; and 

mapping at least one session of a specified PPP protocol of several PPP 
sessions to a same ATM VCC. 

66. A method as claimed 55, wherein it includes the step of multiplexing mini- 
cells into an ATM virtual channel connection (VCC). 
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67. A method as claimed in claim 66, wherein said step Demultiplexing mini- 
cells into an ATM virtual channel connection (VCC) includes multiplexing mini- 
cells encapsulating PPP datagrams and mini-cells encapsulating non-PPP 
datagrams into the ATM VCC. 

68. A method as claimed in claim 67, wherein said PPP traffic data comprises 
voice traffic data. 

69. A method as claimed in claim 55, wherein the multi-protocol datagrams 
are encapsulated into mini-cells of variable lengths. 

70. A method as claimed in claim 55, wherein multi-protocol datagrams 
comprising delay sensitive traffic are encapsulated into mini-cells comprising a 
first channel of an ATM virtual circuit (VC) and datagrams comprising delay 
insensitive traffic are encapsulated into mini-cells comprising a second channel 
of said ATM VC. 

71. A method as claimed in claim 55, wherein said step of assembling mini- 
cells into transport packets comprises assembling mini-cells into ATM packets. 

72. A method as claimed in claim 44, wherein it includes the step of encoding 
a flag in a user to user information (UUI) field of a mini-cell to indicate whether an 
encapsulated datagram extends into a payload of a next mini-cell. 

73. A method as claimed in claim 44, wherein the step of encapsulating a 
datagram in a mini-cell includes inserting the PPP identifier, a payload of the 
datagram and an optional trailer into the payload of the mini-cell. 

74. Apparatus for transporting multi-protocol datagrams over a point to point 
protocol (PPP) link through an asynchronous transport network, comprising: 
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means for encapsulating multi-protocol datagrams into payloads of 
asynchronous transport network mini-cells, each mini-cell having a header in 
addition to a payload, the header including a channel identifier (CID) field; 

means for associating a PPP identifier of a datagram being encapsulated 
into a mini-cell with the CID field of the mini-cell; 

means for assembling said mini-cells into transport packets; and 

means transporting said packets over said point to point link through the 
asynchronous transport network. 

75. A transport apparatus as claimed in claim 74, wherein said means for 
associating a PPP identifier with the CID field of a mini-cell is arranged to insert a 
PPP identifier into the CID field of the mini-cell. 

76. A transport apparatus as claimed in claim 75, wherein the means for 
associating a PPP identifier with the CID field of a mini-cell is arranged to insert 
only a least significant octet of a two octet PPP identifier into the CID field of a 
mini-cell. 

77. A transport apparatus as claimed in claim 76, wherein the means for 
associating a PPP identifier with the CID field of a mini-cell is arranged to insert a 
most significant octet of the PPP identifier in a first byte of the mini-cell payload 
adjacent the header and to indicating the presence of said most significant octet 
in said first byte of the mini-cell payload by making a value of a least significant 
bit (LSB) of the least significant octet to be "1". 

78. A transport apparatus as claimed in claim 74, wherein the means for 
associating a PPP identifier with the CID field of a mini-cell is arranged to assign 
a pre-allocated PPP identifier number to a respective mini-cell CID value and to 
insert the CID value into the CID field of the mini-cell. 
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79. A transport apparatus as claimed in claim 74, wherein the asynchronous 
transport network is an asynchronous transport mode (ATM) network and the 
mini-cells are ATM adaptation layer 2 (AAL2) mini-cells. 

80. A transport apparatus as claimed in claim 79, wherein it includes means 
for scheduling transport of ATM mini-cells of said AAL2 channels according to 
the type of PPP datagrams encapsulated in the mini-cells being transported in 
respective AAL2 channels. 

81. A transport apparatus as claimed 79, wherein it includes means for 
multiplexing mini-cells into an ATM virtual channel connection (VCC). 

82. A transport apparatus as claimed in claim 81, wherein said means for 
multiplexing mini-cells into an ATM virtual channel connection (VCC) is arranged 
to multiplex mini-cells encapsulating PPP datagrams and mini-cells 
encapsulating non-PPP datagrams into the ATM VCC. 

83. A transport apparatus as claimed in claim 79, wherein the means for 
encapsulating datagrams into mini-cells is arranged to encapsulate datagrams 
comprising delay sensitive traffic into mini-cells comprising a first channel of an 
ATM virtual circuit (VC) and encapsulate datagrams comprising delay insensitive 
traffic into mini-cells comprising a second channel of said ATM VC. 

84. A transport apparatus as claimed in claim 79, wherein said means for 
assembling mini-cells into transport packets is arranged to assemble mini-cells 
into ATM packets. 

85. A transport apparatus as claimed in claim 79, wherein said means for 
assembling mini-cells into transport packets is arranged to assemble mini-cells 
directly into MPEG-TS frames. 
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86. A transport apparatus as claimed in claim 79, wherein said means for 
assembling mini-cells into transport packets is arranged to assemble mini-cells 
directly into TDMA time slots. 

87. Apparatus for encapsulating point to point protocol (PPP) datagrams into 
payloads of asynchronous transport network mini-cells, each mini-cell having a 
header in addition to a payload, the header including a channel identifier (CID) 
field, the apparatus comprising: 

means for encapsulating the PPP datagrams into the payloads of the 
asynchronous transport network mini-cells 

means for associating a PPP identifier of a datagram being encapsulated 
into a mini-cell with the CID field of the mini-cell; and 

means for assembling said mini-cells into transport packets. 

88. An apparatus as claimed in claim 87, wherein said means for associating 
a PPP identifier with the CID field of a mini-cell is arranged to insert a PPP 
identifier into the CID field of the mini-cell. 

89. An apparatus as claimed in claim 87, wherein the means for associating a 
PPP identifier with the CID field of a mini-cell is arranged to insert only a least 
significant octet of a two octet PPP identifier into the CID field of a mini-cell. 

90. An apparatus as claimed in claim 89, wherein the means for associating a 
PPP identifier with the CID field of a mini-cell is arranged to insert a most 
significant octet of the PPP identifier in a first byte of the mini-cell payload 
adjacent the header and to indicating the presence of said most significant octet 
in said first byte of the mini-cell payload by making a value of a least significant 
bit (LSB) of the least significant octet to be "1". 

91. An apparatus as claimed in claim 87, wherein the means for associating a 
PPP identifier with the CID field of a mini-cell is arranged to assign a pre- 
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allocated PPP identifier number to a respective mini-cell CID value and to insert 
the CID value into the CID field of the mini-cell. 

92. An apparatus as claimed in claim 87, wherein the asynchronous transport 
network is an asynchronous transport mode (ATM) network and the mini-cells 
are ATM adaptation layer 2 (AAL2) mini-cells. 

93. An apparatus as claimed in claim 92, wherein it includes means for 
scheduling transport of ATM mini-cells of said AAL2 channels according to the 
type of PPP datagrams encapsulated in the mini-cells being transported in 
respective AAL2 channels. 

94. An apparatus as claimed 92, wherein it includes means for multiplexing 
mini-cells into an ATM virtual channel connection (VCC). 

95. An apparatus as claimed in claim 94, wherein said means for multiplexing 
mini-cells into an ATM virtual channel connection (VCC) is arranged to multiplex 
mini-cells encapsulating PPP datagrams and mini-cells encapsulating non-PPP 
datagrams into the ATM VCC. 

96. An apparatus as claimed in claim 92, wherein the means for encapsulating 
datagrams into mini-cells is arranged to encapsulate datagrams comprising 
delay sensitive traffic into mini-cells comprising a first channel of an ATM virtual 
circuit (VC) and encapsulate datagrams comprising delay insensitive traffic into 
mini-cells comprising a second channel of said ATM VC. 

97. An apparatus as claimed in claim 92, wherein said means for assembling 
mini-cells into transport packets is arranged to assemble mini-cells into ATM 
packets. 
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98. An apparatus as claimed in claim 92, wherein said means for assembling 
mini-cells into transport packets is arranged to assemble mini-cells directly into 
MPEG-TS frames. 

99. An apparatus as claimed in claim 92, wherein said means for assembling mini- 
cells into transport packets is arranged to assemble mini-cells directly into TDMA time 
slots. 
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